Cybersecurity Basics: Authentication and Authorization
What is identity and access management?
Identity and access management (IAM) ensures the right people in the right job roles can access the tools, systems, and services absolutely necessary to do their jobs. It is part of the foundation to a strong zero trust approach that answers two fundamental questions you should be asking about every solution you build: who is that and what have we allowed them to do?
The “Who”
Determining who you are is called “authentication.”
This is a process that we encounter all the time. Every time we log in, we’re authenticating to a system.
Usually, we do this with a unique username and password. To provide additional security and assurances, multi-factor authentication is highly recommended.
Multi-factor or two factor authentication is when—in addition to a username and password—the user requires another way of identifying themselves. This often generates a one-time code for a smartphone app or via text message.
The security concept behind this approach is simple. Now to get into an account you must:
- Know the username
- Know the password
- Have access to the device with the one-time code at the same time
Honestly, the username is typically public knowledge. It’s often someone’s email or a public displayed. That leaves something you know (the password) and something you have (the device with the one-time code).
While you can add more ways of verification, like something you are (biometrics) but this approach often strikes the right balance of usable with a good set of security practices.
Building The “Who”
When you are building in the cloud, you’ll deal with this concept in two ways.
The first is proving to your cloud service provider that you are who you say you are.
For your cloud accounts, there is a strong recommendation to use multi-factor authentication. This will help to ensure that only valid users have access to you cloud resources.
The second way you’ll deal with authentication is when you’re building a way for users of your solution to login. Thankfully, a lot of the heavy lifting has already been done for you.
Each of the major cloud providers has a host of options for user authentication. This includes single sign-on systems that will help leverage the accounts and identities you may already have access to.
What Are They Allowed To Do?
Now that you know who is making a request, the next question is “What are they allowed to do?”
This is called authorization.
Usually, authorization expresses permissions and rights granted to a user. The single, most important concept to apply here is called the principle of least privilege.
This is the idea that you should only grant a user the permissions they require to do the task at hand and no more.
Yes, it’s just easier to give everyone administrator rights. You probably are using administrator rights on at least one system you don’t have to right now.
But this approach leads to a lot of security and privacy issues that you do not want to have to deal with. Using the principle of least privilege is a much more effective approach that leads to resilient and reliable systems.
The good news? Each of the big three cloud service providers have a “default deny” environment in place.
This means that by default users (and other entities) can’t do anything.
You need to explicitly grant permissions. This makes it a lot easier to follow the principle of least privilege.
Managing The What
As your environment grows, managing permissions can become a full-time job. No one wants that.
You can apply permissions to users, roles, or other resources directly. Additionally, you can group them together in a policy and apply those policies to users, roles, and resources.
Using policies is definitely the way to go.
While it’s tempting to just assign a required permission to the user or resource that needs them, that’s a recipe for a disaster.
Imagine that you have three people on the team who are working on a database. One of them is pushing out the latest update for your solution and runs into a permissions problem.
The solution? They need an additional permission to the database.
Now you could assign that directly to that team member’s account but what about the other two people who work on the database? They will need this permission as well.
This is where a policy comes into play. Assigning the permissions to the policy and that policy to anyone who needs to accomplish that task is much more efficient.
In this example, we should assign all three team members the “Database workers” policy and that policy assigns the required permissions. Any changes in the permissions will update the policy. This automatically grants the permissions to the three team members assigned to that policy.
This extra abstraction makes managing permissions a lot easier…and yes, users and resources can have more than one policy applied.
What’s Next?
There are other move advanced concepts around authentication (who you are) and authorization (what you are allowed to do) but this post covers the foundations.
Remember two critical takeaways;
- Use multi-factor authentication whenever possible
- Apply the least numbers of permissions to a policy
These two simple guidelines will reduce most of the headaches associated with authentication and authorization as your solution grows. This is yet another example of how applying strong security principles early in the development and design of your solution will save you work and headaches down the road.
